Order Feasibility API
Methods and endpoints
The Order Feasibility API allows you to request an order feasibility check to determine if an order is possible at an address or location.
The following methods and endpoints are included in the Order Feasibility API.
| Endpoint description | Method and endpoint | Function |
|---|---|---|
| API asset version | GET /version | Retrieve the full version number of the API asset (major, minor and patch version numbers). |
| Request Order Feasibility | POST /orderFeasibility | Returns the feasibility status for a potential order, and allocates resources to fulfil the request when submitted. The order feasibility check is based on input criteria, including a Place ID, order type, product offering and product details. The API returns a feasibility status and reason code. If no place meets the search criteria provided, then an error is returned. |
Attributes
The Order Feasibility API includes the following attributes:
| Attribute | Description |
|---|---|
| orderType | The type of order being requested. Used as part of POST /orderFeasibility endpoint to indicate the order type that will be created at an address or location.orderType is always mandatory for all order types: - Connect Primary, Connect Additional ONT, Connect Secondary, Connect and Replace - Change Offer, Modify Attribute, Move Primary, Move Additional ONT - Transfer Primary, Transfer Secondary - Disconnect Primary, Disconnect Secondary. |
| placeId | The placeId is the primary key for the address of the location that the order feasibility is requested for. Used as part of POST /orderFeasibility endpoint to check the placeId at an address or location.placeId is always mandatory for all order types: - Connect Primary, Connect Additional ONT, Connect Secondary, Connect and Replace - Change Offer, Modify Attribute, Move Primary, Move Additional ONT - Transfer Primary, Transfer Secondary - Disconnect Primary, Disconnect Secondary. |
| productOfferId | The productOfferId is the identifier for the product offer or Customer Service Experience (CSE) product offer requested as part of the order feasibility request. Used as part of POST /orderFeasibility endpoint to check the requested product offer, or CSE availability at an address or location from the catalogue.When using the Product Offer Family Type: Bitstream, productOfferId is mandatory for the following order types: - Connect Primary, Connect Additional ONT, Connect Secondary, Connect and Replace - Change Offer, Move Primary, Move Additional ONT, - Transfer Primary, Transfer Secondary. When ordering a CSE from the product catalogue, you can also provide another productOfferId for the following order types: - Connect Primary, Connect Additional ONT, Connect Secondary, Connect and Replace - Change Offer, Modify Attribute, Move Primary, Move Additional ONT - Transfer Primary, Transfer Secondary. When using the Product Offer Family Type: PONFAS Distribution, productOfferId is mandatory for the following order types: - Connect Primary - Modify Attribute - Disconnect Primary. |
| existingProductId | The existingProductId is the identifier of the product that is currently active.Used as part of POST /orderFeasibility endpoint to check feasibility, where either:- an active product is being moved, modified, transferred/replaced or disconnected, or- a secondary or second primary product is being connected,existingProductId is only mandatory for the following order types:- Connect Secondary, Connect and Replace- Change Offer, Modify Attribute, Move Primary, Move Additional ONT- Transfer Primary, Transfer Secondary- Disconnect Primary, Disconnect Secondary.existingProductId is optional for the following order type:- Connect Primary (where you’re activating a primary service when a primary already exists). |
| ontId | The ontId is the identifier of the ONT at the address/location.ontId is optional when there is an intact ONT on the site that the service needs to be activated on.Used as part of POST /orderFeasibility endpoint to check feasibility when connecting or moving a service.ontId is only required for the following order types/scenarios:- Connect Primary (where you’re activating a primary service when a primary already exists)- Move Primary.Note: Providing ontId in order types other than Connect Primary or Move Primary will cause order feasibility request to return an exception code. |
| voiceRequired | Indicates if a voice service is required with the data service provided by the product offer.Not required as input if the requested product offer is a voice only product offer. Default value is: false.Used as part of POST /orderFeasibility endpoint to check feasibility when connecting a product offer with voice.voiceRequired is optional for the following order types:- Connect Primary, Connect Additional ONT, Connect Secondary, Connect and Replace- Change Offer, Move Primary, Move Additional ONT- Transfer Primary, Transfer Secondary. |
| existingProviderName | The existingProviderName is the Chorus system name for the owner of the product that is being replaced.Used as part of POST /orderFeasibility endpoint to check transfer feasibility of product offers at an address or location.existingProviderName is mandatory for the following order types, when the existing product offer is a Business or Education offer:- Transfer Primary, Transfer Secondary.existingProviderName is optional for the following order types, when the existing product offer is a Residential offer:- Transfer Primary, Transfer Secondary.Note: Also see Chorus business rule: Chorus-OrderFeasibility-3. |
Notes:
- Layer 1 products can’t be ordered through the API at this time.
- For more information on all available resources, attributes, parameters, field types, length and other restrictions, see the API Specification.
Learn more about order types
Learn more about CSE product offers
Ordering Secondary Offers
Secondary Offer orders can only be placed if the Primary Service is active.
Note: There is no market segment restriction for Secondary Offers. A Secondary Offer can be provisioned against any active primary Bitstream service irrespective of the market segment.
Supplying existing Provider Name in a feasibility request
The Chorus system name lists the values required in the existing Provider Name field when transferring another customer’s product.
Note: The Chorus system name may differ from the current industry known name.
Learn more about the Chorus Portal Customer List.